Subject: misc. capex comments

From: [email-masked]
Date: Thu, 11 Aug 94 19:13:12 EDT

I have a few comments to add to the recent discussion:

- When we separate the exclusivity CV into one for SNA and
  another for NetBIOS, I think both should be on the list of CVs
  allowed at run-time.

- For CV 87 "TCP Sessions CV", I feel we should use the more standard
  terminology of TCP CONNECTIONS rather than SESSIONS.  All the books
  I've seen on TCP use the term "connection", and "session" has a
  different meaning in the SNA world.  During the first few months of
  discussion in the flow control riglet, there was a lot of confusion
  about DLSw terminology and I would hate to see us introduce any
  more possibility for confusion.  So I vote that all occurrences of
  "session" in the name and text be changed to "connection".

- For CV 88 "Exclusivity", paragraph 2 of the description seems to
  state that if you have a MAC addr or NB name list but do not have
  CV 88, the receiver should assume you had a CV 88 with the indicator
  value of 0x00 ("not exclusive").  I don't like this sort of IMPLIED
  stuff, and would very much prefer we have the following rules:
     - if you include a MAC addr list CV, the MAC addr exclusivity
       list CV must also be included
     - if you include a NB name list CV, the NB name exclusivity
       list CV must also be included
  The converse of these rules is not true, i.e., one could have an
  exclusivity CV without the corresponding list CV.  This is currently
  discussed in paragraph 3, which now needs a little rework because we
  have two exclusivity CVs.  I would like to suggest the following
  wording to replace paragraph 3:

    For the MAC Address List Exclusivity CV:
       A node may specify that it supports no local MAC addresses by
       including in its capabilities the MAC Address List Exclusivity
       CV (with byte 2 == X'01'), and not including any instances of
       the MAC Address List CV.

    For the NetBIOS Name List Exclusivity CV:
       A node may specify that it supports no local NetBIOS names by
       including in its capabilities the NetBIOS Name List Exclusivity
       CV (with byte 2 == X'01'), and not including any instances of
       the NetBIOS Name List CV.

- In CV 89 "MAC Address List", the current text reads "MAC addresses
  and masks are in canonical in this control vector".  I think this
  should be changed to "MAC addresses and masks are in non-canonical
  format in this control vector", per our agreement at the AIW.

- In CV 8A "NetBIOS Name List", I think we should explicitly state that
  '*' is permitted only at the end of a name.  The text implies it but
  should probably state it flat out.  Also, I think we should beef up
  the language about names with trailing blanks/nulls to also treat
  the case of short names which do not end with '*'.  How about this
  for a new 3rd paragraph:

     NetBIOS names which have fewer than 16 bytes and which do not
     end with '*' are not assumed to have a trailing '*';  the
     "wildcard" character must be explicit.  They are also not assumed
     to have any particular trailing pad character, and cannot match
     names with a different length.  Blanks and nulls at the end of
     end of names in this CV are ignored, and should be ignored
     in names being compared to these.

  (not very well worded, maybe someone else can improve on it ....)

- OK you can yell at me for nitpicking but somehow the name
  "SAP List Support CV" doesn't make English sense to me.  How about
  "Supported SAP List CV"?

- I too agree with Frank's proposal that run-time changes to the SAP
  List should not destroy existing circuits.

- I like Paul's table and would suggest the following changes:
    - Clarify that the "required" column only applies to initial capex.
      My understanding is that the required CVs are not required (some
      are not allowed) in the run-time exchange.  I believe there are
      no required CVs in a run-time exchange - you just put the ones
      in that changed.
    - Add a column to indicate which CVs are repeatable, and those are:
         MAC address list, NB name list
    - Add the new exclusivity CV

- Now that I made the point about "required" CVs not being required
  at run-time, I see that the description text for most of the CVs
  which says whether the CV is required, fails to make the distinction
  between initial and run-time capex.  Maybe we should remove the
  text and just use the table with columns "Required at initial
  exchange", "Required at run-time exchange", and "Allowed at run-time
  exchange".

- At the beginning, under "Run-Time Capabilities Exchange" I would
  add a few clarifications:
    - State that initial capex is required but run-time support is
      optional.  (from here on I am stating some new stuff, everyone
      let me know if you agree or not)
      If a node does not support rcvg/using run-time capex and receives
      one, it should discard it quietly (not send back a negative
      response).  If a node supports receipt of run-time capex, it
      should send a positive or negative response as appropriate.  The
      receiver of a negative response to a run-time capex is not
      required to take down its TCP connections with the offended
      partner.
    - Remove the reference to run-time exchange occurring periodically.
      We put run-time in mainly to support dynamic reconfiguration,
      and the notification of a DR event would normally be when it
      happened rather than periodically.
    - State that all the CVs listed are optional and should be
      included only if something changed.

- It may be worth stating somewhere that recipients of the SAP, MAC,
  and NetBIOS lists are not REQUIRED to actually use them to filter
  traffic, etc., either initially or at run-time.

- Finally, I would be in favor of making the formats a little less
  flexible to make parsing easier.  If we discussed all this at some
  AIW and agreed to it then shame on me and I withdraw this suggestion,
  but just looking at it I would say:
    - why not require repeated CVs to be adjacent to their siblings
    - why not require exclusivity to be before its corresponding list
      (making it "advisable" doesn't help anybody, since you would
      still have to write code for the other way)
  It seems to me these rules would make the sender code no harder,
  and the receiver code easier, so why allow the flexibility?

Sorry this ended up so long - I started out to make a handful of
comments and kept coming up with other stuff.

Peter

---

From: Frank Bordonaro <[email-masked]>
Date: Wed, 31 Aug 94 11:48:26 PDT

Peter,

I apologize, somehow I missed your email.
I will go through the suggestions below and let you know 
the current status of each one.

>   another for NetBIOS, I think both should be on the list of CVs

Included in latest proposal on the forum.

>   "session" in the name and text be changed to "connection".

I just changed this in my copy, but I would like to ask that if something is
"clear enough" as is, that we don't change it. There are a lot of people
in this RIG with opinions and this could get out of control.

>        the NetBIOS Name List CV.

I believe we discussed this at an AIW and the group was Ok with
non-exclusive as the default. I think it is too late to change it
for release 1.

>   format in this control vector", per our agreement at the AIW.

My notes from the last AIW say that we decided that MAC addresses and 
masks are canonical in the CapEx and non-canonical in the protocol.
I actually prefer it your way. Can someone help us out here?

>   (not very well worded, maybe someone else can improve on it ....)

Would it be acceptable to you if I add your first sentence to what is 
already there like so...

    All blanks or nulls at the end of NetBIOS names in this control vector 
    are ignored. NetBIOS names which have fewer than 16 bytes and which do 
    not end with '*' are not assumed to have a trailing '*';  the "wildcard"
    character must be explicit.

>   "SAP List Support CV" doesn't make English sense to me.  How about

I have better things to do.

>     - Add the new exclusivity CV

New exclusivity CV was already there and the other two are no in 
the proposal.

>   exchange", "Required at run-time exchange", and "Allowed at run-time

Table should clear it up.

>       included only if something changed.
 
All suggested above changes have been made.
I think we were already covered on item 1 since we decided that if a switch
didn't support something it would ignore it and the lack of a response
implied no support.

>   traffic, etc., either initially or at run-time.

I added the following to the intro

                Capabilities Exchange Filtering Responsibilities
                ------------------------------------------------
                    Recipients of the SAP, MAC, and NetBIOS lists are not 
                required to actually use them to filter traffic, etc., 
                either initially or at run-time.

>   and the receiver code easier, so why allow the flexibility?

My take is that we agreed that the order only mattered on the required CVs
and since we agreed at the AIW, I don't think 1 email should change it.
The receiver code is actually quite easy.

> comments and kept coming up with other stuff.

No kidding. 
 
> Peter

Sorry again for initially missing your mail.
Frank Bordonaro

---

From: Wayne Clark <[email-masked]>
Date: Wed, 31 Aug 94 17:22:58 EDT

[ *** other control vectors deleted *** ]

     [Peter Gayek (IBM) comments]
>>   format in this control vector", per our agreement at the AIW.

 [Frank Bordonaro (cisco) response]
>I actually prefer it your way. Can someone help us out here?

    [Wayne Clark (cisco) response]
    This was the way I recalled it too: MAC addresses in the CapEx (and
    in the MIB, if necessary) will be in canonical form.  The only MAC
    addresses that show up in non-canonical form at those in the
    protocol.

[ *** other control vectors deleted *** ]